home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / sources / std_unix / archive / text0031.txt < prev    next >
Encoding:
Text File  |  1993-07-06  |  6.1 KB  |  109 lines
  1. Submitted-by: nick@santec.boston.ma.us (Nick Stoughton)
  2.  
  3. As the new Usenix standards editor (watch this space for more on this),
  4. I should get this comment on January's Posix.9 meeting published before
  5. we get to the April one...
  6.  
  7.         Report on POSIX.9: FORTRAN Bindings
  8.  
  9. Michael J. Hannah <mjhanna@sandia.gov>, the chair of the POSIX.9
  10. committee, gives his views on the January meeting of the POSIX.9,
  11. and the new POSIX.19 committees.
  12.  
  13. The POSIX.9 (Fortran bindings) group, though sparsely attended, did meet in 
  14. January and made progress towards their next project.  While other IEEE 
  15. standards have been drafted by three people, this is uncommon for POSIX.  A 
  16. committee of such small size implies a very significant reliance on the 
  17. ultimate balloting group.  There is nothing wrong with a small group doing 
  18. the draft, but before such a draft becomes a standard it must be 
  19. reviewed and examined by a much larger, representative, balloting group.  
  20. While there may be nothing improper or illegal with this approach, I
  21. would certainly like to see more participation in our meetings.
  22.  
  23. IEEE Std 1003.9-1992 is approved and was available for purchase at this
  24. meeting.  This standard completely defines how to access ALL
  25. functionality of ISO/IEC 9945-1:1990 from FORTRAN 77, as well as
  26. defining a generalized way to access any operating system structure and
  27. defining byte-stream I/O for FORTRAN 77.  Since FORTRAN 77 is
  28. essentially a subset of the new Fortran 90 standard, IEEE Std
  29. 1003.9-1992 is completely usable in a Fortran 90 environment.  Like any
  30. standards committee that just completed a standard, the committee
  31. discussed how to convince vendors to implement this standard, and how
  32. to convince users to demand this standard from the vendors.
  33.  
  34. Actual work was begun on draft 0 of the next project for this
  35. committee, P1003.19, which is a binding between the Language
  36. Independent Specification (LIS) of 1003.1 and the new Fortran 90
  37. language standard.  This Project Authorization Request (PAR) was
  38. approved by the IEEE standards board in Sept 1992, though approved over
  39. a year ago by the SEC.  Part of the delay was ensuring complete liaison
  40. with X3J3, the Fortran Language committee.  At their August 1992
  41. meeting, the X3J3 approved an official resolution endorsing the scope
  42. of the P1003.19 PAR and agreed to active liaison with the 1003.9
  43. committee.  This is significant since the P1003.19 PAR includes in its
  44. scope the ability to define extensions to the base language standard of
  45. Fortran 90.  One of the major unresolved objections in balloting IEEE
  46. Std 1003.9- 1992 was that many of the functions could have been defined
  47. as simple extensions to the base standard syntax.  For example, mode
  48. bits could be included as an extension to the Fortran OPEN statement,
  49. etc.  Such an approach is planned for the P1003.19 work.
  50.  
  51. The committee began by discussing the overall approach to the new
  52. work.  In addition to examining the new language features in Fortran
  53. 90, the committee discussed how this new binding should relate to the
  54. 1003.1 LIS and its companion 1003.1 C binding.  While this POSIX
  55. standards body is focused on portability of applications, as an end
  56. user I am particularly concerned about portability for application
  57. writers.  Whether to point to the LIS or point to the ``historical
  58. practice'' of C is a contentious issue.  For example, the LIS describes
  59. a procedure called change_file_mode, while the traditional C
  60. function is called chmod.  In IEEE Std 1003.9-1992, because any
  61. function/subroutine name in FORTRAN 77 was exposed to the loader, and
  62. since the IEEE Std 1003.9-1992 routine to change file mode had to be
  63. slightly different than chmod, we had to give it a distinct name,
  64. PXFCHMOD.  Because of the new features of Fortran 90, module
  65. names used by an application are not necessarily exposed to the
  66. loader.  Thus we COULD now call the Fortran 90 routine chmod
  67. without fear of conflict with a different C library routine of the same
  68. name.  Using chmod as the name is intuitive to any programmer
  69. coming from the C world, but is not intuitive to a strictly Fortran
  70. programmer.  While the argument in this example may be stronger for
  71. chmod since there is also a 1003.2 command by that same name,
  72. such an argument does not apply to all 1003.1 functions.  If you really
  73. believe in the concept of the LIS, and especially if the new C binding
  74. is ``thin,'' then a name that is the same as the LIS
  75. change_file_mode might be more appropriate.  A Fortran 90
  76. bindings reader should need at most the 1003.19 binding and the 1003.1
  77. LIS.  However, many LIS names are more than 31 characters, so some
  78. mapping may be required, or an extension to Fortran 90 to recognize
  79. uniqueness in names longer than 31 characters.  This seems to be
  80. something like a religious issue, where parties on each side are
  81. CERTAIN that their position is correct, and the only intelligent
  82. position.  The current committee default is to use the long LIS names,
  83. NOT the familiar C names, but this may change.
  84.  
  85. One item of interest is that new constructs in Fortran 90 seem to
  86. permit the binding to be completely specified as Fortran 90 code
  87. fragments.  Whether the IEEE and ISO document structures could be
  88. accommodated by this is unclear.  For an implementation, you would like
  89. to give an electronic copy of the binding (code fragments) to the
  90. implementor so they could simply add the rest of the code necessary on
  91. their implementation.  Since the code fragments completely define the
  92. application interfaces, this would be a boon for everybody.  However,
  93. such a scheme also raises the question among the lawyer folk as to what
  94. this would mean with regard to the IEEE copyright of the binding.
  95.  
  96. Finally, the committee was actively involved in the hot debate
  97. concerning whether the POSIX Executive Committee should rescind its
  98. mandatory requirement for base POSIX standards to be developed as
  99. Language Independent Specifications (LIS).  As a language binding
  100. committee we are viewed as the direct beneficiaries of the work to
  101. produce an LIS. The members of the bindings committee of both the
  102. 1003.4-Ada and 1003.9-Fortran have strong opinions on this issue.
  103.  
  104. The 1003.9 committee is scheduled to meet the first three days of the April 
  105. POSIX meeting.
  106.  
  107. Volume-Number: Volume 31, Number 34
  108.  
  109.